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Status of This Memo 


This document specifies an Internet standards track protocol for the 
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Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


This document requests IANA registration of an Enumservice for XMPP, 
the Extensible Messaging and Presence Protocol. This Enumservice 
specifically allows the use of ’xmpp’ Uniform Resource Identifiers 
(URIs) in the context of E.164 Number Mapping (ENUM). 
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Introduction 


E.164 Number Mapping (ENUM) [1] uses the Domain Name System (DNS) [6] 
to refer from E.164 numbers [7] to Uniform Resource Identifiers 
(URIs) [3]. Specific services to be used with ENUM must be 
registered with IANA. Section 3 of RFC 3761 describes the process of 
such an Enumservice registration. 


The Extensible Messaging and Presence Protocol (XMPP) [9] provides 
means for streaming Extensible Markup Language (XML) [8] elements 
between endpoints in close to real time. The XMPP framework is 


mainly used to provide instant messaging, presence, and streaming 
media services. 


RFC 4622 [5] registers a Uniform Resource Identifier (URI) scheme for 
identifying an XMPP entity as a URI or as an Internationalized 
Resource Identifier (IRI) [4]. The Enumservice specified in this 
document allows the provisioning of such "xmpp" URIs (and the URI 
representations of "xmpp" IRIs) in ENUM. 

Terminology 

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. 
Enumservice Registration - XMPP 

The following template contains information required for the IANA 
registrations of the ’XMPP’ Enumservice, according to Section 3 of 
RFC 3761: 

Enumservice Name: "XMPP" 

Enumservice Type: "xmpp" 

Enumservice Subtype: n/a 
URI Schemes: "xmpp" 


Functional Specification: 


This Enumservice indicates that the resource identified is an XMPP 
entity. 


Security Considerations: see Section 6 
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Intended Usage: COMMON 

Author: Alexander Mayrhofer <alexander.mayrhofer@enum.at> 
4. XMPP IRI/URI Considerations for ENUM 
4.1. Authority Component 


XMPP IRIs/URIs optionally contain an "Authority Component" (see 
Section 2.3 of RFC 4622). The presence of such an Authority 
Component in an IRI/URI signals the processing application to 
authenticate as the user indicated in the URI/IRI rather than using 
the preconfigured identity. 


In the context of this Enumservice, arbitrary clients may discover 
and use the XMPP URIs/IRIs associated to an E.164 number. Hence, in 
most cases, those clients will not be able to authenticate as 
requested in the Authority Component. 


Therefore, URIs/IRIs that result from processing an XMPP Enumservice 
record SHOULD NOT contain an Authority Component. 


4.2. IRI-to-URI mapping 


while XMPP supports IRIs as well as ’plain’ URIs, ENUM itself 
supports only the use of URIs for Enumservices. 


Therefore, XMPP IRIs MUST be mapped to URIs for use in an XMPP 
Enumservice record. The mapping MUST follow the procedures outlined 
in Section 3.1 of RFC 3987. 


5. Example 
An example ENUM entry referencing to a XMPP URI could look like: 
SORIGIN 6.9.4.0.6.9.4.5.1.1.4.4.el64.arpa. 
@ IN NAPTR ( 100 10 "u" 


"E2U+xmpp" 
"I*,.*S!xmpp:some-user@example.com!" 
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6. Security and Privacy Considerations 


General security considerations of the protocols on which this 
Enumservice registration is based are addressed in Sections 3.1.3 and 
6 of RFC 3761 (ENUM) and Section 14 of RFC 3920 (XMPP). 


Since ENUM uses DNS -- a publicly available database -- any 
information contained in records provisioned in ENUM domains must be 
considered public as well. Even after revoking the DNS entry and 


removing the referred resource, copies of the information could still 
be available. 


Information published in ENUM records could reveal associations 
between E.164 numbers and their owners -- especially if IRIs/URIs 
contain personal identifiers or domain names for which ownership 
information can be obtained easily. 


However, it is important to note that the ENUM record itself does not 
need to contain any personal information. It just points to a 
location where access to personal information could be granted. 


ENUM records pointing to third-party resources can easily be 
provisioned on purpose by the ENUM domain owner -- so any assumption 
about the association between a number and an entity could therefore 
be completely bogus unless some kind of identity verification is in 
place. This verification is out of scope for this memo. 


7. IANA Considerations 
This memo requests IANA to add a new "XMPP" Enumservice to the 
‘Enumservice Registrations’ registry, according to the definitions in 


this document and RFC 3761 [1]. 


The required template is contained in Section 3. 
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This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 
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